Forum des exercices du projet Zuul

Exercice 7.43

  
 
Avatar Denis BUREAU
Exercice 7.43
par Denis BUREAU, vendredi 6 avril 2018, 08:21
 
Implement a trapdoor somewhere (or some other form of door that you can only cross one way).

1) Une trap door n'est pas une trap room. La pièce concernée doit avoir au moins deux sorties, mais l'une d'entre-elles ne doit être franchissable que dans un seul sens. A ce stade, une solution très simple peut être utilisée.

2) Mais comment doit se comporter la commande back ?
     Si on veut empêcher la commande back d'autoriser le franchissement "à l'envers" de la trap door, il serait pratique de disposer dans la classe Room d'une nouvelle méthode isExit(Room) qui renvoie vrai ou faux selon que la Room passée en paramètre est une des sorties de la pièce ou pas.

3) Ajoutez une 2ème trap door quelque part dans votre jeu.
Attention ! Si vous avez dû modifier plus d'une ligne de code, c'est que l'exercice n'est pas bien réalisé.

Contraintes (pour ne pas faire de mauvaise implémentation de cette fonctionnalité) :
- Le nom ou la description des pièces ne doivent jamais être utilisés dans les tests que vous ferez pour déterminer si vous êtes dans le cas d'une Trap Door.
- Il devra être possible d'ajouter autant de Trap Doors que l'on souhaite sans ajouter de vérifications supplémentaires dans le code.
- Il doit aussi être possible de positionner plusieurs Trap Doors dans une même pièce.
- Si une Trap door est positionnée dans la première pièce du jeu, celle-ci doit posséder au moins une autre sortie qui peut être franchie dans les deux sens.

Aide : Si vous ne trouvez pas une méthode dans la classe Stack, cherchez dans les méthodes de la classe Vector puisqu'elle en hérite.

Précision : Il n'est pas nécessaire de créer une classe Door (l'exercice 7.45 est optionnel).

Ne pas oublier de lire les échanges ci-dessous pour mieux comprendre la bonne manière de réaliser cet exercice.

Avatar Hassan DIAB
Re: Exercice 7.43
par Hassan DIAB, mardi 19 novembre 2013, 20:50
 

La solution serait-elle :

du moment que l'on traverse ce "trapdoor", on doit supprimer toute les "room" dans le Stack grace à une méthode de la Class Stack ?

Avatar Denis BUREAU
Re: Exercice 7.43
par Denis BUREAU, mardi 19 novembre 2013, 23:21
 

Si vous parlez de la commande back, une bonne solution consiste effectivement à vider la pile des Rooms.

Avatar Julien KRYWYK
Re: Exercice 7.43
par Julien KRYWYK, vendredi 22 novembre 2013, 08:52
 

Bonjour,

Pour cette question, nous avons crée une HashMap<Room, Door> dans la class Room. Celle ci associe à une Room (correspondant à une sortie de la Room actuelle) une porte de la classe Door. 

On place les portes de la Room actuelle grâce à :

public void setExit(final String pDirection, final Room pNeighbor, final Door pDoor)

Cependant, cela nous oblige à créer dans GameEngine toutes les portes...

N'y a t'il pas une autre méthode?

Avatar Denis BUREAU
Re: Exercice 7.43
par Denis BUREAU, vendredi 22 novembre 2013, 13:12

La question ci-dessus et ma réponse ci-dessous concernent plutôt l'exercice 7.45.

Si.

L'idée est plutôt de "mimer" la HashMap des sorties et donc de définir une HashMap<String,Door> en fonction des directions.

Ensuite, la procédure setExit devrait créer la porte en interne et l'ajouter à la HashMap, ce qui n'ajouterait pas de lignes dans createRooms.

Avatar Victor OU
Re: Exercice 7.43
par Victor OU, dimanche 24 novembre 2013, 18:43
 

Est-ce correct si nous n'avons pas créer de classe Door pour cette exercice?

Je ne vois pas l'intérêt de cette classe pourriez-vous expliquer car j'ai fais cet exercice seulement en ne définissant aucune Room de sortie pour la Trap Room ce qui ne permet donc pas de retourner en arrière ni avec la méthode goRoom ni la méthode back.

Quels attributs devra avoir cette classe? Quelle sera son rôle?

De plus pourriez-vous détailler ce que vous entendez par "créer la porte en interne"?

 

Cordialement.

Avatar Denis BUREAU
Re: Exercice 7.43
par Denis BUREAU, dimanche 24 novembre 2013, 20:35
 

> Est-ce correct si nous n'avons pas créer de classe Door pour cette exercice?

oui, tout à fait, cette classe n'est utile qu'à l'exercice (optionnel) 7.45 ;
par contre, une fois cet exercice fait, il peut être nécessaire de revenir sur le 7.43 ...

> Je ne vois pas l'intérêt de cette classe pourriez-vous expliquer car j'ai fais cet exercice seulement en ne définissant aucune Room de sortie pour la Trap Room

Attention !
On ne demande pas une trap room mais une trap door !
La Room dans laquelle se trouve cette trap door est censée avoir d'autres sorties.

> ce qui ne permet donc pas de retourner en arrière ni avec la méthode goRoom ni la méthode back.

si vous adoptez une méthode simple comme celle que vous évoquez, il faudra probablement modifier la commande back pour qu'elle ne permette pas le retour "à l'envers de la trap door"

> Quels attributs devra avoir cette classe? Quelle sera son rôle?
> De plus pourriez-vous détailler ce que vous entendez par "créer la porte en interne"?

Si vous décidez de faire l'exercice 7.45 et que que ces questions sont toujours d'actualité, posez-les sur le forum de l'exercice 7.45.

Avatar Mohamad KHALED
Re: Exercice 7.43
par Mohamad KHALED, jeudi 19 décembre 2013, 01:01
 

Bonjour,

je voulais savoir s'il vous plait si pour implémenter cette trapdoor il suffit de supprimer une des exit et de supprimer ce qui a dans la pile une fois on passe par le trapdoor.

Cordialement.

Avatar Denis BUREAU
Re: Exercice 7.43
par Denis BUREAU, jeudi 19 décembre 2013, 09:29
 

tout à fait

Avatar William AFONSO
Re: Exercice 7.43
par William AFONSO, mercredi 28 mai 2014, 19:55
 

Bonjour, est-il possible de récupérer une clé d'une Hashmap? car je ne vois pas de moyen de tester si l'on s'apprête à rentrer dans la salle où se trouve la TrapDoor...

Dans ma commande back:

 

 if (command.getSecondWord() == "North" && aCurrentRoom.getString() == "Donjon")
            gui.println("La porte est fermée à clef!");

 

J'aurai pu me passer de la String associée à cette Room mais cela revient au même puisque  je n'arriverait pas à comparer la Room dans le if...

Quelqu'un peut m'aider?

Avatar Denis BUREAU
Re: Exercice 7.43
par Denis BUREAU, mercredi 28 mai 2014, 20:42
 

Je ne vois pas comment répondre à votre question, mais quelques remarques :

1) On peut récupérer toutes les clés d'une HashMap grâce à la méthode keySet.

2) Une trap door n'est pas une porte fermée à clef, mais une porte qu'on ne peut franchir que dans un seul sens.

3) Lorsqu'on va d'une pièce A vers une pièce B, on peut toujours vérifier qu'il y a bien une sortie de A vers B.

4) Il n'y a pas de second mot pour la commande back.

En espérant que cela vous aidera à remanier votre code.

Avatar Denis BUREAU
Re: Exercice 7.43
par Denis BUREAU, vendredi 30 mai 2014, 10:36
 

L'étudiant a répondu :

En fait, je veux tester si l'on s'apprête à rentrer dans la salle Donjon de mon jeu. La variable vDonjon étant seulement dans le createGame() de mon GameEngine, je ne vois pas comment tester "si la sortie de la pièce nord est vDonjon et qu'on va au nord", ou même "si la pièce contient une sortie vDonjon et qu'on va au nord", alors on supprime la stack. C'est en fait le vDonjon que je n'arrive pas à indiquer au test.
Alors, effectivement, je pourrais récupérer les clés de la HashMap mais je n'aurait que des Nord, Sud etc... et pas des Room.
Avatar Denis BUREAU
Re: Exercice 7.43
par Denis BUREAU, vendredi 30 mai 2014, 10:43
 

1) 'Alors, effectivement, je pourrais récupérer les clés de la HashMap mais je n'aurait que des Nord, Sud etc... et pas des Room.'
Si !  Quand vous demandez à votre HashMap ce qui est associé à la clé "North", elle vous retourne bien une Room !

2) Je ne suis pas sûr qu'il faille tester tout ce que vous décrivez. Une 'porte normale' entre les pièces A et B se franchit dans les deux sens uniquement parce-que vous avez prévu une sortie de A vers B et une sortie de B vers A. Une 'trap door' ne doit pouvoir être franchie que dans un seul sens : la solution paraît donc très simple ... non ?

Avatar Denis BUREAU
Re: Exercice 7.43
par Denis BUREAU, vendredi 30 mai 2014, 14:10
 

L'étudiant a répondu :

D'après ce que j'ai lu sur le forum, l'exercice de la TrapDoor, va au-delà d'affecter une sortie franchissable que dans un sens. En effet, vous dites qu'il faut aussi effacer la stack. Or, comment savoir quand effacer la stack? Dans mon jeu, c'est lorsque l'on s'apprête à rentrer dans le Donjon par la sortie nord de la pièce courante. Donc, il faut récupérer la salle Donjon pour la rentrer dans le test, non?
 

J'ai trouvé une alternative en testant: si mes seules sorties sont nord, est et ouest et que je vais au nord alors stack vidée. Mais j'ai pu faire cela, seulement parce qu'il se trouve que je n'ai qu'une salle ayant ces sorties précises dans mon jeu. Mais, si cela n'avait pas été le cas, j'aurai été obligé de passer par ce que je vous ait expliqué dans le paragraphe ci-dessus, non?

Avatar Denis BUREAU
Re: Exercice 7.43
par Denis BUREAU, vendredi 30 mai 2014, 14:13
 

La solution décrite dans votre 'alternative' n'est évidemment pas correcte, puisque comme vous l'avez très bien remarqué, elle ne fonctionnerait pas si une autre Room avait les mêmes sorties.

Dans la commande back, pour savoir si vous venez de franchir une 'trap door', ne suffit-il pas de regarder s'il existe ou pas une 'exit' dans l'autre sens permettant de revenir à la pièce précédente ?

Avatar Denis BUREAU
Re: Exercice 7.43
par Denis BUREAU, vendredi 20 mai 2016, 10:33
 

Un étudiant a écrit :

Pour l'exercice de la trap door j'ai d'abords supprimer une sortie d'une salle pour pouvoir rentrer dans celle-ci mais pas en sortir. Puis dans ma méthode back j'ai rajouter un if comme dans le code si dessous j'aimerais savoir si cette technique est la bonne ?

 if(aPlayer.getCurrentRoom().getDescription().equals(" dans la salle de cours, tu ne peux plus retourner dans l'escalier il semblerait qu'il ai bouger ! ") ) {
       aGui.println ( "Dans cette salle tu ne peux plus retourner en arrière");     
}  

Avatar Denis BUREAU
Re: Exercice 7.43
par Denis BUREAU, vendredi 20 mai 2016, 10:38
 

- pour la commande go, votre solution est suffisante

- pour la commande back, il vaudrait mieux utiliser la solution évoquée dans la toute première question sur cet exercice
  (en effet, une simple coquille dans la String que vous utilisez dans equals empêcherait le test de fonctionner)

Avatar Johan POGNON
Re: Exercice 7.43
par Johan POGNON, dimanche 20 novembre 2016, 17:18
 
J'ai utilisé la méthode proposé par Hassan DIAB (poste du mardi 19 novembre 2013, 20:50)

"La solution serait-elle :

du moment que l'on traverse ce "trapdoor", on doit supprimer toute les "room" dans le Stack grace à une méthode de la Class Stack ?"

Du coup, pour vider le Stack, j'effectue un teste dans le goRoom après avoir affecté la valeur de la nextRoom à l'attribut currentRoom. Ce teste regarde si le nom de l'image de la currentRoom est identique à celle de la trapDoor. J'aurais pu comparer la description des room (au lieu des nom de l'image).

J'avais au départ pensé à comparer les room entre elles mais impossible car nous créons les room avec des variables locales situées dans le createRoom().

Donc ma question est, y aurait-il un autre moyen plus "rigoureux" dont je serai passé à côté afin de comparer la currentRoom et la trapRoom (au lieu de faire comme j'ai fait avec les noms des images)?

Avatar Denis BUREAU
Re: Exercice 7.43
par Denis BUREAU, mardi 22 novembre 2016, 09:21
 

La bonne méthode pour détecter une TrapDoor (et non une TrapRoom) est de s'apercevoir qu'il n'y a pas de sortie de B vers A (alors qu'il y en a une de A vers B) ; cela permet d'être indépendant de tout nom de pièce ou d'image.

Avatar Denis BUREAU
Re: Exercice 7.43
par Denis BUREAU, vendredi 6 avril 2018, 08:15
 

Un étudiant a écrit :

Comment vide t'on une stack? Pour l'instant j'utilise cette methode
private void viderStack() {
        for(int i=0;i<100;i++){
            this.aBackRoom.pop();
        }
    }
mais je me doute qu'il y a un autre moyen
cependant sur JavaPlateform aucune méthode ne semble pouvoir...

Avatar Denis BUREAU
Re: Exercice 7.43
par Denis BUREAU, vendredi 6 avril 2018, 08:29
 

Même s'il n'y avait pas d'autre moyen, ce code est à l'évidence faux, puisqu'il dépile systématiquement 100 fois sans savoir combien d'éléments ont été empilés !

Vous pourriez donc au moins écrire une boucle qui ne dépile que ce qui a été empilé.

Mais vous avez raison, il y a un autre moyen, en un simple appel de méthode.

Par contre, je ne connais "JavaPlateform" !?
Il faut tout simplement regarder dans la Javadoc (taper java 8 Stack dans google).

Attention ! J'ai ajouté une aide dans l'énoncé, car la méthode clear que vous cherchez est dans les méthodes héritées (inherited), et non directement dans la classe Stack.